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ABSTRACT 

IR  synthetic  scene  fidelity  improves  with  each  leap  ahead  in  computing  capability.  Military  training,  in  particular,  is 
reaping  the  benefits  from  each  improvement  in  rendering  fidelity  and  speed.  However,  in  order  for  these  synthetic 
scenes  to  be  useful  for  signature  virtual  prototyping  or  laboratory  observer  trials,  a  particularly  challenging  aspect  still 
needs  to  be  addressed.  Synthetic  scenes  need  to  have  the  ability  to  include  robust  physically  reasonable  active  source 
prediction  models  for  vehicles  and  to  include  physically  reasonable  interaction  of  vehicles  with  the  terrain.  Ground 
heating  from  exhaust,  radiative  heating  and  reflections  between  the  vehicle  and  terrain,  and  tracks  left  on  the  terrain  are 
just  some  examples  of  desired  capabilities.  For  determining  the  performance  of  signature  treatments,  the  effects  must 
be  more  than  artistic  renderings  of  vehicle  terrain  interaction,  but  physically  representative  enough  to  make  engineering 
determinations.  This  paper  will  explore  the  results  of  a  first  phase  study  to  include  MuSES  targets  in  an  existing  IR 
synthetic  scene  program  and  the  inclusion  of  exhaust  impingement  on  the  terrain. 

Keywords:  Signature,  Infrared,  visual  signature,  modeling,  exhaust,  FCS,  materials,  metrics,  SMART,  MATREX, 
virtual  prototype 


1.0  INTRODUCTION 

IR  synthetic  scenes  are  used  in  a  variety  of  military  and  commercial  applications.  The  “fidelity”  of  these  scenes  has 
improved  dramatically  as  computation  power  increases.  The  word  fidelity  here  is  used  in  the  sense  of  physical 
representation,  i.e.  how  “good”  something  looks  subjectively.  There  is  also  the  physics  “fidelity”  (or  accuracy)  of  a 
simulation.  This  refers  to  the  level  to  which  a  simulation  includes  such  effects  as  validated  first  principles  temperature 
prediction  models;  first  principles  predicted  effects  in  nature— such  as  solar  heating  and  reflections,  atmospheric 
absorption,  thermal  shadowing;  or  more  resource  intense  effects  such  as  computational  fluid  dynamics  in  describing 
exhaust  plumes  and  impingement  effects  or  the  use  of  the  bi-directional  reflection  distribution  function  (BRDF).  In 
simulations  addressing  ground  vehicles,  these  effects  have  been  addressed  in  a  variety  of  degrees,  but  many  simulations 
estimate  these  effects  if  they  are  addressed  at  all.  The  physics  short  cuts  used  in  these  simulations  may  in  many 
applications  be  reasonable;  however,  in  areas  such  as  signature  analysis  of  vehicles  or  identification  friend  or  foe,  they 
may  not.  There  is  an  ongoing  effort  in  the  Army  to  create  an  IR/Vis  synthetic  scene  that  has  the  predictive  physics 
fidelity  needed  to  address  the  more  demanding  signature  analysis  arena  as  well  as  other  related  areas  such  as  advanced 
sensor  design. 

1.1  The  Ideal 

Figure  1  shows  a  notional  diagram  of  what  the  perfect  simulation  of  this  sort  would  include.  Since  we  are  dealing 
specifically  with  the  topic  of  target-terrain  interactions,  the  items  in  dashed  lined  boxes  are  the  phenomena  specific  to 
this  topic  and  the  items  in  dot  dashed  lined  boxes  are  items  that  are  related.  Clearly  the  ideal  simulation  would  be  quite 
an  undertaking  to  do  well.  Therefore  a  group  of  like-minded  organizations  are  coming  together  in  a  collaboration  to 
develop  such  a  simulation.  This  will  give  us  the  ability  to  leverage  a  diversity  of  expertise  and  multiple  resources. 


Report  Documentation  Page 


Form  Approved 
OMB  No.  0704-0188 


Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 


1.  REPORT  DATE 

01  MAY  2003 


2.  REPORT  TYPE 

Journal  Article 


4.  TITLE  AND  SUBTITLE 

An  Exploration  of  Vehicle-Terrain  Interaction  in  IR  Synthetic  Scenes 


6.  AUTHOR(S) 

Teresa  Gonda;  Dave  Less;  David  Filbeec;  Erik  Polsen;  Timothy 
Edwardsd 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

US  Army  TACOM  RDEC  (TARDEC),6501  East  Eleven  Mile 
Rd,MS263, Warren, Mi, 48397-5000 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

US  Army  TACOM  RDEC  (TARDEC),  6501  East  Eleven  Mile  Rd, 
MS263,  Warren,  Mi,  48397-5000 


3.  DATES  COVERED 

01-04-2003  to  30-04-2003 

5a.  CONTRACT  NUMBER 

5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

5d.  PROJECT  NUMBER 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 

#13878 

10.  SPONSOR/MONITOR'S  ACRONYM(S) 

TARDEC 

11.  SPONSOR/MONITOR'S  REPORT 
NUMBER(S) 

#13878 


12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

14.  ABSTRACT 

IR  synthetic  scene  fidelity  improves  with  each  leap  ahead  in  computing  capability.  Military  training,  in 
particular,  is  reaping  the  benefits  from  each  improvement  in  rendering  fidelity  and  speed.  However,  in 
order  for  these  synthetic  scenes  to  be  useful  for  signature  virtual  prototyping  or  laboratory  observer  trials, 
a  particularly  challenging  aspect  still  needs  to  be  addressed.  Synthetic  scenes  need  to  have  the  ability  to 
include  robust  physically  reasonable  active  source  prediction  models  for  vehicles  and  to  include  physically 
reasonable  interaction  of  vehicles  with  the  terrain.  Ground  heating  from  exhaust,  radiative  heating  and 
reflections  between  the  vehicle  and  terrain,  and  tracks  left  on  the  terrain  are  just  some  examples  of  desired 
capabilities.  For  determining  the  performance  of  signature  treatments,  the  effects  must  be  more  than 
artistic  renderings  of  vehicle  terrain  interaction,  but  physically  representative  enough  to  make  engineering 
determinations.  This  paper  will  explore  the  results  of  a  first  phase  study  to  include  MuSES  targets  in  an 
existing  IR  synthetic  scene  program  and  the  inclusion  of  exhaust  impingement  on  the  terrain. 

15.  SUBJECT  TERMS 

Signature,  Infrared,  visual  signature,  modeling,  exhaust,  FCS,  materials,  metrics,  SMART,  MATREX, 
virtual  prototype 


16.  SECURITY  CLASSIFICATION  OF: 


a.  REPORT 

unclassified 


b.  ABSTRACT 

unclassified 


c.  THIS  PAGE 

unclassified 


17.  LIMITATION  OF 

18.  NUMBER 

ABSTRACT 

OF  PAGES 

Public  Release 

11 

RESPONSIBLE  PERSON 


Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


Figure  1  The  Ideal 


1.2  The  Context  of  this  effort 

Figure  2  shows  the  context  of  the  actual  simulation  development  effort.  The  (as  yet  un-named)  collaboration  under 
which  this  effort  is  being  conducted  is  almost  worth  studying  as  much  as  the  topic.  It  is  an  informal  cooperation 
between  two  formal  Army  Science  and  Technology  Objectives  (STOs),  leveraging  a  cooperative  agreements  with 
industry  (CRADA),  an  international  exchange  agreement  between  the  US  and  UK,  several  Small  Business  Innovative 
Research  Contracts  (SBIR)  and  more. 

The  approach  in  developing  this  tool  has  been  to  break  it  apart  into  pieces  that  can  be  addressed  by  the  different 
organizations  with  the  appropriate  expertise.  For  instance,  one  of  the  early  projects  addressed  the  first  bottleneck — 
CAD  migration.  In  figure  2,  this  is  the  area  that  falls  between  the  “Inputs”  and  “Thermal  Physics  Preprocessing”. 
Current  efforts  have  focused  on  easing  the  transition  from  commercial  CAD  programs  such  as  Pro/E  into  analytical 
models— a  process  that  traditionally  has  required  much  expertise  and  great  tedium.  Currently,  it  can  take  up  to  80  hours 
to  translate  geometry  from  a  CAD  system,  clean  up  the  inevitable  errors  and  prepare  the  converted  geometry  for 
analysis.  Recent  improvements  in  the  process  have  reduced  this  time  considerably.  For  example,  now,  Pro/E  vehicle 
CAD  models  can  be  directly  exported  to  the  thermal  model  MuSES  (Multi-Service  Electro-optical  Signature  code) 
from  within  Pro/E  Mechanic— which  can  then  also  import  and  display  MuSES  results  (predicted  temperatures). 

1.3  The  Target  Thermal  Model 

One  of  the  important  assumptions  in  this  process  is  that  one  has  a  legitimate  target  model  in  the  first  place  that  one 
wishes  to  integrate  into  a  synthetic  scene  in  some  fashion.  We  mentioned  MuSES  above.  Since  MuSES  is  a  robust 
predictive  routine  designed  for  rapid  prototyping  and  is  touted  as  the  Army  standard  model  for  this  purpose 1 ,  it  makes 
sense  to  leverage  its  performance.  MuSES  can  also  predict  terrain  temperatures  as  well— however;  it  is  only  a  thermal 
model  (not  visual)  and  even  given  improved  computer  performance,  it  is  also  our  belief  that  more  research  needs  to  be 
done  in  this  area  before  one  could  rely  on  an  extreme  fidelity  first  principles  synthetic  scene  over  two  kilometers  square 
or  more  to  create  the  ideal. 

After  the  thermal  modeling  process,  the  target  must  be  inserted  into  a  synthetic  scene,  as  illustrated  in  figure  2.  Here  is 
where  the  challenges  arise.  As  described  in  the  ideal,  this  rendering  code  must  have  task-appropriate  atmospherics  and 


sensor  effects  applied  and  then  generate  images  that  can  be  assessed  in  a  perception  lab  or  analyzed  against  certain 
metrics— again,  depending  on  the  task.  Once  this  is  accomplished,  changes  can  be  made  to  the  target,  the  sensor,  or  the 
type  of  experiment  and  then  the  process  can  be  repeated. 
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Figure  2  A  Collaborative  Effort 


1.4  The  Synthetic  Scene 

Our  research  led  us  to  chose  two  synthetic  scenes.  One  is  the  popular  Paint-the-Night  (PTN)  IR  scene  simulation.  PTN 
is  based  on  Open-GL,  is  capable  of  real  time  performance,  and  has  HLA  and  non-HLA  versions.  It  is  developed  and 
used  by  NVESD  primarily  for  advanced  sensor  performance  modeling  and  it  is  now  being  distributed  to  other 
organizations.  The  second  is  Cameo-Sim  (CS)  developed  in  the  UK  under  MoD  (DSTL)  sponsorship  for  signature 
simulation.  CS  is  a  broadband  scene  simulation  software  system  that  produces  32-bit  imagery  of  natural  static  and 
moving  (non-real  time)2  terrestrial  scenes.  Output  imagery  includes  visible  and  IR  in  true  and  false  colour  (0.4  and  20.0 
pm  in  any  user-defined  waveband).  Each  model  brings  certain  strengths  to  the  table  and  we  believe  that  in  using  both 
in  this  study,  we  will  strengthen  the  knowledge  base,  maintain  a  risk  reduction  strategy  and  benefit  a  wider  range  of 
users. 


Plume  Interaction 


Reflections 
of  Plume 
off  Target 


Radiation 
to  Target 


Convection 
to  Target 

Radiation 
to  Terrain 


Convection 
to  Terrain 


Plume  Radiance  Seen  by  Sensor 


Plus 

•  Conduction  between  two 

•  Maintaining  shared  effects  from  atmosphere 
(weather/clouds)i.e.  predictions  of  both  stem 
from  identical  conditions. 


Figure  3  Defining  the  interaction 


1.5  Defining  the  specific  vehicle-terrain  interactions 

Outside  the  ideal,  we  have  not  yet  identified  the  specific  phenomena  we  plan  to  incorporate  when  we  talk  about  vehicle- 
terrain  interaction.  Now  we  will  define  how  we  will  work  towards  simulating  the  interaction  between  the  two.  The 
effects  that  we  will  address  are  shown  in  figure  3.  Most  are  due  to  the  exhaust  of  the  vehicle  that  may  impact  the 
terrain  through  convection  and  radiation.  Additional  interactions  occur  where  the  vehicle  touches  the  ground,  such  as 
conduction,  track  effects,  and  ground  and  dust  displacement.  Also,  the  interaction  between  the  two  models  must  be 
addressed  from  a  software  engineering  perspective.  In  general,  if  two  simulations  such  as  these  are  being  combined,  we 
must  make  sure  that  they  are  synchronized  in  terms  of  weather  and  all  other  aspects.  We  have  the  choice  of  linking  the 
two  models  together  using  HLA  (High  Level  Architecture)  or  by  imbedding  the  MuSES  library  into  the  synthetic  scene 
program.  Eventually  we  may  exploit  architecture  within  MATREX3  (Modeling  Architecture  for  Technology  and 
Research  Experimentation— formerly  VDLMS  (Virtual  Distributed  Laboratory  for  Modeling  and  Simulation))  to 
combine  the  two.  For  now,  we  have  chosen  the  "imbedded"  method  for  the  proof-of-principle  stage. 

2.0  THE  APPROACH 

We  have  identified  the  target  model,  the  synthetic  scene,  and  the  notional  steps  that  must  be  taken  along  with  the  effects 
we  believe  are  important.  Next,  we  need  an  implementation  strategy  to  get  us  to  our  goal.  We  have  taken  the  approach 
of  developing  this  capability  in  stages  with  a  proof-of-concept  demonstration  at  each  stage.  During  each  stage,  we  will 
be  able  to  take  lessons  learned  and  use  them  to  develop  an  approach  for  integrating  into  other  simulations  or  collection 
of  simulations,  such  as  MATREX3. 

2.1  Allowing  for  the  effects  within  the  target  model  first 

While  developing  the  implementation  strategy,  the  tasks  were  initially  broken  down  into  more  detail.  Figure  4  shows 
these  tasks  through  the  pipeline  involved  in  achieving  the  goal:  1  predict  the  surface  temperature,  2.  link  to  CFD  codes 
for  the  exhaust  effects,  3.  render  the  plume  with  appropriate  radiation  effects  and  4.  link  to  the  synthetic  scene. 


TASK  OVERVIEW 


Pipeline:  Thermal  -  CFD  -  Plume  Radiance  -  Background 


Thermal  Embedded  in  Scene  Code 


Figure  4  Another  look  at  the  task  breakout 


As  a  matter  of  practicality,  we  decided  to  try  to  embed  the  capabilities  of  predicting  the  exhaust  in  the  target  model  as 
much  as  possible  for  a  stand-alone  capability  for  rapid  prototyping  and  in  parallel  determine  integration  path  to 
synthetic  scene.  The  first  three  tasks  can  all  be  implement  in  the  stand-alone  MuSES  code  and  distributed  to  the  user 
community.  The  fourth  task  will  then  require  us  to  have  those  effects  interact  with  the  synthetic  code. 

3.0  STATUS 

Task  1  Predict  surface  temperature:  Completed.  There  is  ample  literature  on  MuSES  as  a  valid  simulation  tool  for 
predicting  vehicle  temperatures4  so  we  are  confident  that  task  1  is  complete  under  the  majority  of  circumstances.  It  is 
important  to  note  that  MuSES  is  under  constant  development  and  improvements  and  validation  are  ongoing  for  MuSES 
by  many  organizations  in  government  and  industry.  Up  until  this  latest  release  (version  7.0)  many  users  wanting  the 
engine  predictive  capabilities  and  flexibility  of  PRISM  needed  to  use  PRISM  to  generate  the  response  curves  and  then 
input  them  into  MuSES.  With  the  release  of  version  7.0  and  a  generic  engine  model  and  with  the  release  later  this  year 
of  hook  functions  for  users  to  write  their  own  routines,  this  capability  will  be  finally  fully  within  MuSES.  As  far  as 
this  study  is  concerned  however,  the  task  is  completed. 

Task  2  Generate  exhaust  plume:  Partially  completed.  This  task  involves  automatically  generating  an  exhaust  plume. 
We  must  use  caution  when  using  the  word  "automatic".  While  some  parameters  can  be  set  as  default,  this  will  never  be 
a  simple  exercise  (unless  a  model  has  already  been  set  up  and  validated)  and  will  require  persons  knowledgeable  in  this 
area.  Today,  engineers  can  predict  the  exhaust  flow  using  a  CFD  code,  which  gives  plume  geometry  and  temperatures 
and  flows.  MuSES  has  links  to  commercial  CFD  codes  such  as  FLUENT  and  STAR  CD  and  we  are  working  towards 
putting  in  the  hooks  to  work  with  public  domain  NASA  codes  in  order  that  organizations  that  cannot  afford  commercial 
CFD  license  fees  will  still  be  able  to  take  advantage  of  this  capability.  Figure  5  shows  an  example  of  a  notional  plume 
prediction  with  the  associated  geometry  for  a  Bradley.  This  geometry  was  created  manually,  however  and  was  not 
generated  automatically.  Automating  this  process  is  the  challenge  and  is  underway. 


CFD  Predicted  Exhaust  Impingement 
on  Terrain  within  MuSES 


Task  2:  CFD  Links  with  MuSES 
and  automated  plume  geometry 


Figure  5  CFD  results  with  automated  plume  geometry  and  example  of  exhaust  impingement  on  a  MuSES  terrain 


Figure  5  also  shows  scenes  from  an  animation  of  an  exhaust  plume  within  MuSES  heating  a  terrain  as  the  vehicle 
moves  over  the  terrain.  Notice  the  ground  heat  and  cool  as  the  vehicle  moves  over  the  terrain  .  As  a  proof-of-concept, 
this  part  of  the  task  has  been  completed,  but  was  done  manually.  The  goal  is  to  automate  this  process  and  have  it 
nteract  with  a  full  synthetic  scene  tenderer.  Task  2  therefore  is  50%  completed. 

Task  3  Render  Plume  with  Radiation:  In  progress.  As  figure  3  shows,  in  addition  to  the  convective  effects  that  will  be 
implemented  via  the  CFD  code,  there  are  radiative  effects  as  well.  By  using  radiative  codes  such  as  SPURC  and 
SIRRIM  III,  the  proof-of-concept  images  in  figure  6a  and  6b  were  generated.  Again,  the  images  were  generated  with 
much  user  intervention  (and  in  this  case  with  spurious  data  to  eliminate  and  classification  issues)  .  There  are  many 
challenges  ahead  to  automate  this  process  and  have  it  link  to  the  output  from  task  2. 


Figure  6b  has  enough  realism  in  the  image  to  start  begging  the  question— what  is  “good  enough”.  In  this  area  as  in  most 
it  will  depend  on  the  task.  A  helicopter  designer  looking  to  suppress  the  exhaust  will  be  much  more  concerned  about 
where  the  actual  flow  goes  under  certain  circumstances  than  say  a  sensor  designer  looking  at  the  helicopter  2  km  away. 
Approximately  30%  complete. _ 

Task  3:  Integrating  a  Plume  code  Task  3:  BRDF  rendering  with 

Plume  Image 

•  Example  of  2D  image  predicted  by  SPURC  and 
SIRRM  III 

♦  MWIR  simulation  of  2D  ground  vehicle  exhaust 


Figure  6  (a)  Plume  Radiance  code  image,  (b)  Example  plume  image  rendered  with  BRDF 

Task  4  Link  to  Synthetic  scene:  This  next  stage  is  in  some  ways  the  most  challenging.  Bringing  several  simulations 
together  is  always  problematic.  In  this  case,  it  is  not  simply  a  matter  of  needing  a  common  architecture  or  method  of 
passing  information.  In  order  to  make  the  task  more  reasonable,  we  have  broken  the  task  into  four  levels  of  complexity 
as  listed  in  table  1. 

3.1  Defining  the  Levels  of  Interaction  Between  Vehicle  and  Terrain  Models 

These  definitions  are  one  of  the  bi-products  of  this  study.  It  is  our  hope  that  these  definitions  can  be  refined  within  the 
community  and  be  used  as  a  vehicle  for  discussing  the  differences  in  simulations  of  this  sort. 


Vehicle-Terrain 
Interaction  Level 

What  it  stands  for  ... 

Level  0 

The  synthetic  scene  reads  in  the  target  file  and  renders  it.  Temperatures 
on  the  target  come  from  the  target  model.  The  synthetic  scene  renders 
appropriate  radiation.  No  interaction  between  target  and  background.  The 
user  ensures  time  and  weather  correlation  between  target  and  scene 

Level  1 

No  radiative  interaction  between  target  and  scene,  but  target  temperature 
and  scene  temperatures  are  time  and  weather  correlated 

Level  2 

As  Level  1,  but  target  temperatures  are  affected  by  the  scene 

Level  3 

As  Level  2,  but  scene  temperatures  are  affected  by  the  target 

Table  1.  The  Levels  of  Vehicle-Terrain  Interaction.  5 


Level  0  is  literally  a  cut  and  paste  and  then  render.  Most  training  simulators  take  this  approach  because  it  is  the 
quickest  and  accomplishes  much  of  what  the  simulation  needs.  The  images  in  figure  7  show  geometry  that  has  been 
imported  in  the  Cameo-Sim  (CS)  scene  generator.  Since  the  synthetic  scene  does  radiative  effects  between  the  target 
and  the  terrain  (not  for  heat  transfer,  but  from  a  rendering  perspective),  you  get  these  effects  for  free.  The 


consequences  to  this  level  are  that  the  target  temperatures  will  have  been  calculated  using  a  thermal  target  simulation 
(TTS)  thermal  environment  that  would  not  necessarily  be  consistent  with  that  defined  within  the  Synthetic  Scene 
Render  (SSR)  scene.  Secondly,  there  is  no  time-of-day,  orientation  or  altitude  consistency.  Thirdly,  the  background  and 
target  cannot  thermally  influence  one  another,  whether  through  radiative  or  conductive  means  or  through  sky 
obscuration.  Currently,  this  is  the  status  for  CS  and  PTN. 


A 

Figure  7  Level  0  type  of  imagery  within  Cameo-Sim.  A  future  concept  with  no  background.  Same  concept  inserted  into  a  scene. 

And  a  land  rover  in  another  scene. 


Level  1:  Synthetic  Scene  software  interacts  with  target  model  software  at  level  1.  Opens  target  file,  synchronizes 
material  properties  (for  proper  rendering)  and  feeds  back  the  weather  scenario  to  the  target  model  -  drives  the  target 
model.  No  direct  interaction  between  target  and  terrain.  In  this  level,  the  TTS  will  be  called  by  the  SSR  at  rendering 
time  once  the  target  has  been  located  within  a  scene  and  after  atmospherics  have  been  assigned.  Once  a  target  is 
positioned  within  a  scene,  the  thermal  target  simulation  will,  in  principle,  be  able  predict  the  target’s  temperatures 
based  on  an  atmosphere  definition  that  has  been  matched  to  the  assigned  SSR  atmospheric  definition  (eg.  the  correct 
time-of-day,  orientation,  altitude  conditions,  etc).  The  TTS  can  then  correctly  and  with  consistency  solve  the  target’s 
temperatures  for  a  target  located  within  that  SSR  scene.  But  similarly  to  Level  0,  there  will  be  no  thermal  interaction 
modeled  between  the  target  and  background  in  this  level.  Status:  This  is  currently  in  progress. 

Level  2:  Scene  Influences  Target:  At  this  level,  the  thermal  influence  of  the  background  on  the  target  will  also  be 
considered.  As  in  Level  1  though,  there  will  be  no  thermal  influence  of  the  target  on  the  background  modeled.  In  this 
case,  the  temperature  predictions  for  the  background  will  remain  within  the  SSR  and  independent  of  the  target.  SSR 
feeds  the  TTS  appropriate  surrogate  terrain  geometry  local  to  the  target  and  radiation  &  conduction  interaction  occurs 
on  in  target  model  only.  Resulting  radiative  reflections  will  occur  on  terrain  via  the  scene  tenderer.  When  the  target  is 
moving  an  infinite  plane  (geometryless)  background  of  the  appropriate  type  can  be  used.  Shadowing  of  the  target  by 
trees,  etc.,  is  ignored.  Status:  Planned. 

Level  3:  Target  Influences  Scene:  Same  as  level  2,  but  now  plume  impinges  on  surrogate  terrain.  These  effects  plus 
plume  information  are  fed  back  to  terrain  model  for  final  rendering.  When  the  target  is  moving,  the  target  interacts 
with  a  “scrolling”  faceted  terrain.  Status:  Planned.  There  are  numerous  complications  involved  with  this  task,  not  the 
least  of  which  is  that  CS  uses  pixel  based  shadowing  and  MuSES  uses  polygon  based  shadowing.  Trying  to  blend  the 
predicted  terrain  between  the  two  poses  a  challenge.  A  feasibility  study  has  determined  some  possibilities.  Status: 
Planned. 


Ratio  of  correct  to  incorrect  responses 
Moderate  Clutter 


Simulated  Low 
Quality 

Simulated  High 

Quality 

Real 


Ratio  of  correct  to  incorrect  responses 
High  Clutter 


Simulated  Low 
Quality 

Simulated  High 

Quality 

Real 


Time  limit 


Time  limit 


Figure  8  The  results  from  the  Time  Limited  Search  Study 
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Figure  9  Some  images  from  the  Time  Limited  Search  Study 


3.2  How  good  is  good  enough? 

As  we  develop  this  capability,  there  is  a  question  that  lingers  in  the  background.  We  hinted  at  this  in  the  plume 
discussion  above.  Before  a  simulation  is  developed,  there  need  to  be  boundaries  set— requirements  specifications.  We 
have  asked  that  the  model  address  certain  phenomena,  but  how  do  we  know  when  it  is  “good  enough”?  Some 
simulations  do  not  account  for  these  effects— are  they  really  that  important?  The  answer  to  this  question  is  the  same  as 
any  similar  question  asked  of  a  simulation— it  depends.  It  always  depends  on  the  task  the  model  is  asked  to  perform. 
The  truth  is,  so  much  is  unknown  that  the  number  of  unanswered  questions  in  the  signature  arena  is  substantial6.  We 
cannot  give  exact  specifications  in  this  circumstance,  but  we  can  bound  the  problem  along  the  way  by  using  the  tool 
itself.  We  will  leverage  tried  and  true  methods  for  determining  level  of  goodness  in  these  situations,  such  as  one  in  use 
at  Night  Vision  Electronics  Sensors  Directorate  at  CECOM. 

Edwards  and  Vollmerhausen  et  al7  conducted  a  time  limited  search  study  using  measured  imagery  and  wished  to  use 
simulated  (synthetic)  imagery  (see  figure  9)  as  well.  They  asked  themselves— was  the  synthetic  imagery  up  to  the  task? 
They  used  metrics  specific  to  their  task  to  determine  whether  their  simulated  scenes  were  appropriate  to  their 
experiment. 

In  this  case  (time  limited  search  studies  at  tactical  ranges)  higher  quality  simulated  scenes  gave  a  good  performance 
match  to  real  images — particularly  in  higher  clutter. 

We  will  design  task  oriented  perception  experiments  based  on 
measured  scenes  and  determine  tasked  based  metrics  to  use  against 
synthetic  scenes  to  determine  if  the  target-terrain  modeling  we 
develop  is  necessary  or  sufficient. 

For  now,  experience  says  we  must  include  these  effects  to  some 
degree  to  the  best  of  our  ability.  Exhaust  impingement  on  vehicle 
and  ground  can  be  a  large  LWIR  cue  depending  on  clutter  and 
view  angle  -  especially  for  ATRs— see  the  measured  image  in 
figure  10. 

In  addition,  in  making  resolution  and  geometry  representation 
choices,  we  must  be  aware  of  the  effect  described  here  by  Curry 

"The  Stinger  flight  software,  to  enhance  guidance  accuracy  against  certain  types  of  targets,  has  used  edge-tracking 
algorithms  extensively.  This  software  feature  can  create  considerable  simulation  accuracy  problems  for  systems  with 
low-resolution  scene  generation  equipment.  In  triangle  based  systems  such  as  the  one  that  is  being  replaced  with  this 
system,  the  simulation  seeker  will  tend  to  track  on  pointed  objects  such  as  the  tips  of  triangles;  on  pixel  based  systems, 
the  seeker  will  track  the  tip  of  an  individual  pixel  or  in  the  corner  between  two  pixels.  To  eliminate  problems  such  as 
these,  the  scene  generator  must  have  a  finer  resolution  than  the  missile  seeker.  The  “movie  generation  ’’  software  must 
not  only  produce  scenes  with  correct  spatial  and  intensity’  attributes  as  related  to  the  missile  seeker,  it  must  also 
properly  convolve  the  entire  scene  to  accurately  match  the  seeker’s  optics  and  detector  blur  circle ,8  "  [emphasis  added] 


3.3  Software  Readiness  Levels 

The  Army  is  striving  to  develop  metrics  of  goodness  for  technology  and  software.  These  are  referred  to  as  "readiness 
levels".  We  have  taken  the  general  definitions  of  Software  Readiness  Levels  and  described  them  for  this  exercise. 
This  can  be  found  in  table  2.  As  we  develop  this  capability,  we  will  use  these  definitions  to  describe  our  progress. 
Currently  we  sit  at  SRL  3. 


Figure  10.  Measured  image  of  T72  with 
exhaust  plume  impingement 


and  Combs: 


SRL  Definitions  based  on  SRL  guidance 


Technology  Readiness  Level 

Description 

1.  Basic  principles  observed 
and  reported. 

Lowest  level  of  software  readiness.  Basic  research  begins  to  be  translated  into 
applied  research  and  development.  Examples  might  include  a  concept  that  can 
be  implemented  in  software  or  analytic  studies  of  an  algorithm’s  basic  properties. 

2.  Technology  concept 
and/or  application 
formulated. 

Invention  begins.  Once  basic  principles  are  observed,  practical  applications  can 
be  invented.  Applications  are  speculative  and  there  is  no  proof  or  detailed 
analysis  to  support  the  assumptions.  Examples  are  limited  to  analytic  studies. 

3.  Analytical  and 

experimental  critical 
functions  and/or 
characteristic  proof  of 
concept. 

Active  research  and  development  is  initiated.  This  includes  analytical  studies  to 
produce  code  that  validates  analytical  predictions  of  separate  software  elements. 
Examples  include  software  components  are  identified  and  partially  integrated. 
Demonstrate  that  a  vehicle  can  be  taken  from  CAD  into  predictive  scene  without 
target/terrain  interaction,  simple  atmosphere  and  sensor  effects  and  basic 
metrics.  Pieces  exist  and  linkages  can  be  done  manually,  but  integration  paths 
identified. 

4.  Component  and/or 

breadboard  validation  in 
laboratory  environment. 

Basic  software  components  are  integrated  to  establish  that  they  will  work 
together.  They  are  relatively  primitive  with  regard  to  efficiency  and  reliability 
compared  to  the  eventual  system.  While  individual  elements  have  a  high  level  of 
validation,  no  validation  effort  on  entire  simulation  has  been  performed. 

5.  Component  and/or 

breadboard  validation  in 
relevant  environment. 

Reliability  of  software  ensemble  increases  significantly.  The  basic  software 
components  are  integrated  with  reasonably  realistic  supporting  elements  so  that  it 
can  be  tested  in  a  simulated  environment.  Concepts  are  taken  through  the 
process  and  perception  lab  experiments  are  performed.  The  results  are 
compared  to  perception  lab  experiments  of  comparable  measured  scenes. 

Path  to  link  with  MATREX  is  defined.  Software  releases  are  Alpha’  versions  and 
configuration  control  initiated.  Verification,  Validation  and  Accreditation  (VV&A) 
initiated. 

6.  System/subsystem  model 
or  prototype 
demonstration  in  a 
relevant  environment. 

Representative  model  or  prototype  system,  which  is  well  beyond  that  of  TRL  5,  is 
tested  in  a  relevant  environment.  Represents  a  major  step  up  in  software- 
demonstrated  readiness.  Examples  include  testing  a  prototype  in  a  live/virtual 
experiment  or  in  simulated  operational  environment.  Algorithm  run  on  processor 
or  operational  environment  integrated  with  actual  external  entities.  Software 
releases  are  ‘Beta’  versions  and  configuration  controlled.  Software  support 
structure  in  development.  VV&A  in  process. 

7.  System  prototype 
demonstration  in  an 
operational  environment. 

Represents  a  major  step  up  from  TRL  6,  requiring  the  demonstration  of  an  actual 
system  prototype  in  an  operational  environment,  such  as  in  a  command  post  or 
air/ground  vehicle.  An  actual  test  site  is  simulated.  Tests  are  run  to  determine 
input  sensitivities  and  necessity  of  2nd  and  3rd  order  physics  effects.  MATREX 
integration  path  begins.  Software  support  structure  in  place.  Software  releases 
are  in  distinct  versions.  Frequency  and  severity  of  software  deficiency  reports  do 
not  siqnificantly  deqrade  functionality  or  performance.  VV&A  completed. 

8.  Actual  system  completed 
and  “flight  qualified” 
through  test  and 
demonstration. 

Software  has  been  demonstrated  to  work  in  its  final  form  and  under  expected 
conditions.  The  perception  tests  of  actual  field  test  sites  and  the  ones  generated 
synthetically  have  compared  favorably.  This  TRL  represents  the  end  of  system 
development.  The  tool  can  be  used  in  stand-alone  mode.  The  path  to  MATREX 
integration  is  completed.  Software  releases  are  production  versions  and 
configuration  controlled,  in  a  secure  environment.  Software  deficiencies  are 
rapidly  resolved  through  support  structure. 

Table  2.  The  Software  Readiness  Levels  of  this  capability 


4.0  SUMMARY 


This  is  a  multi-organization  effort  based  on  extreme  fidelity  criteria  specific  to  signature  management  and  analysis.  We 
have  demonstrated  success  in  identifying  or  developing  the  individual  pieces  required  to  simulate  exhaust  impingement 
effects  using  current  CFD  codes  and  plume  codes.  The  challenges  that  lie  ahead  are  in  automating  the  process  and  the 
interface  between  the  two  models.  We  have  developed  what  we  hope  to  become  a  standard  definition  of  levels  of 
interaction  between  simulations  of  these  sorts  and  we  hope  others  will  critique  and/or  adopt  these  definitions.  We  have 
completed  what  we  have  defined  as  a  level  0  vehicle-terrain  interaction  in  this  effort  and  level  1  is  in  progress.  We 
currently  are  at  a  Software  Readiness  Level  of  3.  There  is  a  plan  under  development  for  validation  and  “level  of  detail 
required”  analyses.  And  finally,  lessons  learned  will  be  migrated  to  larger  M&S  efforts  (MATREX).  We  will  have  a 
demonstration  of  an  automated  capability  of  level  0  schedule  for  this  August,  2003.  This  program  is  currently  un¬ 
named  but  currently  falls  under  the  Army’s  new  RDE  Command. 
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